Guión para la presentación de retrospectiva 1

Guión preliminar por	Presentador	Tiempo
Antonio Rodriguez	Antonio Rodriguez	15 min

1. OBLIGATORIO

Opener

Hoy es dia 12 de Marzo de 2024, y hace 6 semanas que comenzamos el proyecto. A lo largo de estas semanas hemos tenido momentos mejores, momentos peores, y hemos aprendido mucho de ellos. Hoy vamos a hacer una retrospectiva del estado general del proyecto tanto a nivel grupal como individual, analizar que problemas ha habido, como se han manejado y que problemas tenemos actualmente.

Reloj del proyecto

Comenzaremos con el reloj del proyecto por que creo que es una de las herramientas mas útiles para analizar el estado del proyecto junto con el seguimiento de las tareas, que nos permiten saber como vamos con respecto a la planificación incicial, y mas concretamente me gustaria separar este análisis en dos partes, la primera a nivel grupal, y la segunda a nivel individual.

Reloj hasta la entrega de DP

Vamos a partir de la base de una estimacion de 10 horas semanales por miembro a lo largo de 15 semanas que son las que constituyen las 150 horas equivalentes a 6 creditos ECTS. Eso nos da una estimación de 170 horas semanales y 510 horas durante las primeras 3 semanas. Las horas reales equivalen a 678 por lo que en este aspecto, de forma grupal, observamos una diferencia sustancial de 168 horas, que es un 33% mas de lo estimado. Las causas principales de este desfase encontramos que son dos:

• Una es el tiempo inefectivo, 208 horas se van entre asistencia y ver videos, otra es la adaptacion a un entorno de trabajo con tantas personas, que ha sido mas lento de lo esperado y ha conllevado problemas de comunacion notables, y la ultima es el tiempo dedicado a entablar las primeras conversaciones con las ONGs, una de ella solicito que fuera en persona y ahi se fueron 18 tecnico-horas entre transporte y reunion ya que particparon 3 miembros del equipo.

Reloj del Sprint 1

En el Sprint 1, siguiendo la misma estimación de 170 horas semanales tenemos una estimacion de 340 horas para este Sprint, sin embargo el trabajo real ha sido de de 458 horas. Haciendo una retrospectiva de los problemas encontrados durante el Sprint los problemas residen en dos puntos principales:

• El primero es la comunicación en si, que dio problemas entre backend y frontend, basicamente nos encontramos con que al final del Sprint no podiamos juntar estos dos modulos y se gasto mucho tiempo arreglando por ambas partas la raiz de estos problemas.
• El segundo es, de nuevo, que creemos que hay un exceso de horas "no efectivas" que se van en asistencia y en ver videos, que componen juntos 130 horas del tiempo consumido. El tema de los videos ya lo hemos abordando creando tareas de hacer resumen y apuntes de las pildoras teóricas, y hemos pensado en una posible solucion para las horas de asistencia, que sería que para semanas no evaluables solo vengan a clase los encargados de presentar, dos personas para tomar apuntes, y el resto de miembros, si quieren, se queden en casa e invirtiendo esas horas en el proyecto.

Individual DP

Pasando al aspecto individual, durante las primeras 3 semanas vemos que todo el mundo cumple el minimo pero se nota obviamente una diferencia entre los que mas y los que menos, aunque la diferencia es progresiva. La media se encuentra en 40 horas y la desviacion estandar en 6 horas. Durante estas semanas se encuentra con mas horas Alvaro Bernal que estuvo planificando todos los procesos internos ya que se establecio como PM, le siguen Jose Miguel y Javier Garcia que echaron mucho tiempo en crear los mockups, jose miguel ademas estuvo formandose en las nuevas tecnologias para trasladar el conocimiento al resto y javier fue a las reuniones con las ONG, le sigue Joaquin por la misma ultima razon. Ya a de aqui hacia abajo las horas son mucho mas constantes y tenemos con menos horas ronald david y alejandro gallardo, pero por la simple razon de las tareas que se le fueron asignando no eran tan complejas, o no tenian tantos errores. Cabe destacar aqui que la desviacion se hace creciente durante la ultima semana por que no se estimo bien la semana anterior y que esta diferencia de tiempo con respecto al resto de compañeros aparece en la ultima semana y no durante las otras dos, donde los ultimos puestos los ocupan otros compañeros.

Individual Sprint 1

En las semanas del Sprint 1 tenemos una media de 27 horas y una desviacion estandar de 4 horas, por lo que en este aspecto la desviacion es menor que la anterior. En este caso el primer puesto, Gonzalo, fue la persona encargada de preparar todo lo que es el backend, el uso de FastAPI, seguidos por Alvaro Gonzalez que tambien estuvo con la presentacion ademas del backend y de Joaquin que se encargo de gestionar los despliegues. Por la parte de abajo tenemos a Alvaro Bernal que durante DP echo mas horas que nadie y durante el Sprint 1 bajamos su carga de tareas para que pudiera descansar un poco mas. Por el resto de miembros no tenemos una desviación notable, tan solo de 7 horas entre el que más y el que menos que consideramos que es un margen aceptable considerando tambien que todos los miembros cumplen el minimo.

Vista General

Si consideramos todo el tiempo hasta ahora si que vemos una desviacion importante tambien de 30 horas entre el que más horas ha echado y el que menos. Los que mas horas han echado son Jose Miguel, Javier, Gonzalo y Joaquin como personas más involucradas en el proceso de desarrollo, seguidos por Fran Alberto y Alvaro Bernal que han estado mas implicados en las presentaciones. En la parte baja de las horas tenemos a Alejandro Gallardo, Alejandro Medina, Ronald y David, que no es que consideremos que han hecho poco pues cumplen bien con sus responsabilidades pero quizas tendriamos que corregir el como hacemos el reparto de tareas para que sea mas equitativo.

Responsablidades de Tareas

Y ya que hablamos de tareas hablemos de las responsabilidades de cada miembro durante lo que llevamos de proyecto, ser responsable de una tarea implica:

• No solo hacerla, si no informar de los problemas relacionados con esa tarea y que se acabe a tiempo o justificar su retraso
• Ademas de por supuesto ser responsable de la calidad final de la tarea.

Durante la primera fase del proyecto todo el mundo hizo tareas de documentación por que consistian la gran mayoria de las tareas, pero a partir del Sprint 1 si comenzamos a diferenciar las responsabilidades de cada miembro.

Diapo con tabla persona fila y tipo de tarea columna

Como podeis ver aqui durante el Sprint 1 Alvaro Gonzales, Gonzalo, Joaquin, Alberto, David, Alejandro Gallardo y Jose María fueron los responsables del backend, mientras que Jose Miguel, Nicolas, Javier, Fran, Ronald y Manuel se encargaron del frontedn. En cuanto a las tareas de documentacion ahora mismo solo se encargan de ellas los coordinadores que son Alvaro Bernal, Marco, Alejandro Medina y yo, Antonio, pero durante el Sprint 1 tambien lo hicieron Jose María, Jose Miguel, Manuel, Javier, Joaquin y Ronald.

Diapo con tabla detallada

Las responsabilidades tambien las almacenamos en la BGCI para un seguimiento mas de cerca y registro de que tareas se hace responsable cada miembro.

Rendimiento individual

Y estas tareas hay que medirlas de alguna forma, y para ello hemos iterando de distintas formas sobre como medirlos. De forma resumida durante la fase de Devising a Project simplemente medimos la cantidad de tareas completadas a tiempo entre la cantidad de tareas asignadas, pero durante el Sprint 1 fuimos refinando las metricas de rendimiento para que hubiera un concenso en cual es una manera justa de medirlo.

Actualmente hemos definido mediciones para: Coordinadores, Analistas y Desarrolladores.

La nota de de un coordinador se calcula haciendo una encuesta a los miembros de un grupo en base a su capacidad de distribucion de tareas, seguimiento del trabajo, comunicacion efectiva, toma de decisiones y la gestión de problemas y plazos.

La nota de los analistas se calcula en base a las notas internas de sus tareas de documentación, que tienen su propia rubrica basada en la claridad del contenido, la exhaustividad, la relevancia, la coherencia, la originalidad, la precision tecnica, la presentacion visual si es necesario algun grafico, el cumplimiento de estándares y la calidad de la redacción.

Por ultimo a los desarrolladores también se les mide con un formulario la calidad del codigo,la seguridad en backend y diseño en frontend, el cumplimiento de estandares y la comunicacion.

Performance evaluation

Tabla de evaluacion DP

Como en Devising a Project no teniamos unas metricas bien desarrolladas para medir el rendimiento, el resultado de todos los miembros fue del 100% de rendimiento, pero para el Sprint 1 si hemos sacado metricas mas interestantes.

Tabla de evaluacion Sprint 1

Como podemos ver en la tabla de Sprint 1 la media del rendimiento es de 91% con la mayoria de las personas sobre el 80 de rendimiento. El mayor indice de rendimiento ha sido de 100% el menor de 77% Las personas con menor rendimiento durante este Sprint han sido Manuel y Ronald de frontend, no al hacer la media de sus respectivas notas pero en el frontend en especifico, y despues de discutirlo en privado creemos que es por falta de conociento de las tecnologias, lo que les ha hecho que tarden mas en hacer sus tareas o que no esten listas a tiempo. Tambien hemos planteado cambiar las responsabilidades de estas personas para que desarrollen sus habilidades lo mejor posible.

Commitment Agreement

Continuando con el estado del acuerdo de compromiso. Nosotros medimos en este apartado 5 puntos principales: El cumplimiento minimo de una dedicacion de 10 horas semanales, el respeto al horario de disponibilidad establecido, la compensación de tiempo si una semana se inverte mas y otra no llega a las 10 horas, la realizacion de las tareas asignadas dentro de plazos o justificacion de su retraso, y por ultimo la correcta aplicación del sistema de avisos.

En terminos generales el cumplimiento ha sido del 100%, y de manera individual, la mayoria de los miembros lo han cumplido al 100% hasta ahora. Aquellos que no se ha debido a una falta de comunicacion efectiva provocando retrasos significativos en las tareas de los demas. Estos han sido Jose Maria durante la semana 4 y Manuel durante las semanas 4 y 5.

2. OPCIONAL

Análisis de la metodología

Pasando a hablar de nuestra metodologia me gustaria hablar de ella desde dos puntos de vista. El primero desde el punto de vista grupal y despues también a nivel de código para ver que cosas nos han dado problemas y como las estamos solucionando.

Por un lado a nivel grupal lo que manejamos sobre todo es una metodologia para dividir el trabajo entre los distintos equipos y departamentos. Inicialmente todas las tareas las creaba y repartia coordinacion pero despues nos dimos cuentas que habia muchas cosas, sobre todo en lo que respecta a las tareas de codigo que no podiamos repartir, por lo que eso se empezo a delegar a los equipos de backend y frontend.

Despues tambien habiamos desarrollado una metodologia de seguimiento del trabajo en excel, pero despues nos dimos cuenta de que requeria de muchas tarras manuales y cambiar cosas en distintas hojas, lo que al final lo hacia todo mas dificil de analizar desde un punto de vista global, por eso pasamos a gh project y ahora mismo estamos trabajando en crear un "template" que trate de juntar toda la informacion en un mismo sitio. De igual forma hemos pasado los documentos importantes y se continua haciendo toda la documentacion en docosaurus para poder gestionar mejor la automatizacion de estadisticas y control de versiones.

Diapo del tablero de coordinacion

Por otra parte a nivel de codigo estamos siguiendo una metodologia agil con Sprints y division de tareas por semanas, usamos gitflow para la gestion de nuevas caracteristicas y establecemos puertas de calidad y revisiones para poder mergear una rama a otra. En este aspècto si notamos un problema en backend porque al principio se necesitaban 2 revisores para poder aceptar una PR, pero como eso hizo que se atrasaran mucho la intergracion de tareas se ha reducido a 1.

Calidad del proyecto

Por otro lado tambien queremos comentar como medimos la calidad del trabajo, tanto a nivel de código como a nivel de tareas de documentación

Pasar a diapo con valores de codacy

Primero, con codacy hacemos un análisis estático del código, y nos ayudamos de github actions para bloquear o permitir el merge de una rama si superan o no los estándares de calidad.

Por otro lado tambien medimos la cobertura de codigo, que establecemos que tiene que superar el 80% para que una tarea se considere completada y mayoritariamente libre de errores.

Actualmente tenemos 21 "issues" en ambos reposititorios de frontend, todos de estilo de codigo, y 69 en backend, la mayoria de estilo de codigo, cinco de code smell y uno uno de seguridad.

En coverage tenemos un 90% y 91% en los repositorios de frontend y un 86% en los repositorios de backend.

Pasar diapo

Por otro lado también integramos Bluejay, en este caso en los repositorios de backend y frontend de CyC para que nos ayude a medir y analizar el uso de buenas prácticas de manejo de incidencias e integración de características en ambos repositorios.

Pasar a diapo con valores de bluejay

Con bluejay podemos medir que el flujo de las tareas sea de Todo, a en progreso creando una rama, a revisión con un pull request, y a done con un merge. Tambien nos ayuda a ver quienes participan en la revisión de pull requests, si hacen comentarios positivos o negativos, si se aceptan finalmente o se rechazan, o si todo lo anterior sigue los estándares de nomenclatura establecidos.

Diapo con stats

Bueno primero quiero decir aqui que por alguna razon bluejay no mide todas las estadisticas de ambos repositorios, hemos visto que esto es comun con otros grupos tambien.

En la primera metrica vemos que frontend supera a backend con un 65% sobre un 20% de correlacion entre marcar como done una tarea y mergearla. Hemos consultado a los equipos y nos han dicho que creen que la metrica es asi de baja porque ellos primero hacen el merge y despues cierrar las issues.

Por otro lado frontend tiene un 100% de cumplimiento en comentarios positivos en PR frente a un 70% en backend, y la ultima metrica medida, que no se ha medido en backend, es la correlacion entre poner una issue en review y crear una PR. De nuevo, nos comentan que primero estan creando la PR y despues moviendo la issue a In Review.

Grado de implicación y motivación

Por ultimo quiero hacer un analisis de como ha avanzado la motivacion del grupo a lo largo del Sprint.

Al inicio del proyecto podemos observar que casi todo el mundo tiene un alto grado de motiviacion, o esta motivado hasta cierto punto, quitando una persona que estaba altamente desmotivada.

Conforme avanzamos en Devising a Project vemos que la motivacion cae un poco. Por una parte el grafico al final de devising a project creemos que es algo normal. Suele pasar que uno esta mas motivado antes de hacer algo, que cuando ya lo esta haciendo.

Pero en el Sprint 1 si que vemos que cae significativamente, solo el 7 personas tienen algo de motivacion en el proyecto. Esto lo podemos atribuir a la cantidad de problemas tempranos que hemos encontrado en el desarrollo. Tanto de integracion, como de comunicacion, como de no llegar a deadlines, etc.

Aun asi parece que las cosas estan mejorando despues de aplicar planes de contingencia y reorganizar un poco los procesos interno ya que de una mayoria indeferente o desmotivada hemos pasado a una mayoria con cierto grado de motivacion.

De la encuenta que hemos hecho los motivos mas recurrentes de la caida de entusiasmo por el proyecto resultan ser:

• Impotencia por falta de conocimiento
• Sensacion de una comunicacion pobre en algunos casos
• Sensacion de pasividad por parte de algunos miembros
• Cansacio y agotamiento
• Alta carga de trabajo
• No saber si se van a cumplir los objetivos